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I INTRODUCTION 


HGH  (Hierarchical  Developaent  Hethodology)  was  created  at  SRI 
International,  with  support  from  the  Navy  under  Contract  N00123-76-C- 
0195  (Hethodology  for  Modular  Operating  Systems),  to  aid  in  the 
development  of  embedded  computer  systems  that  are  more  correct, 
reliable,  and  maintainable  than  those  produced  by  conventional  methods. 
In  an  unrestricted  enviroiaent,  HDM  has  the  potential  of  greatly  aiding 
software  development.  However,  the  Navy  has  particular  needs  associated 
with  its  own  software-development  prooess  [1]  *.  Thus,  for  HDM  to  be 
of  benefit  to  the  development  of  Navy  software,  it  must  be  possible  to 
Integrate  HDM  into  the  Navy's  software-development  process  without 
sacrificing  either  the  special  merits  of  HDM  or  the  integrity  of  Navy 
procedure. 

The  goal  of  this  report  is  to  show  that  the  use  of  HDM  is 
consistent  with  the  Navy  software-development  process,  and  how  some  of 
the  Information  provided  by  HDM  (e.g.,  formal  specifications),  can  be 
used  directly  in  Navy  software  documents  to  supplement  or  replace  the 
information  normally  found  there.  The  conclusions  are  that  HDM  and  the 
standard  Navy  documents  can  be  integrated  with  no  trouble,  resulting  in 
sore  standardization  of  the  documents  than  would  be  possible  using  the 
current  guidelines  alone. 

This  report  first  briefly  describes  HDM,  and  then  characterizes  a 
possible  relationship  between  HDM  and  the  standard  Navy  systems 
documents  known  as  the  PPS  (Program  Performance  Specification),  the  PDS 
(Program  Design  Specification) , and  the  SOW  (Statement  of  Work) . 


* References  are  listed  at  the  end  of  the  report. 
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II  A BRIEF  DESCRIPTION  OF  HCH 


1 


i 


HOH  Is  an  integrated  set  of  concepts,  languages,  and  tools  designed 
to  enable  the  production  of  large  software  systeas  that  are  correct, 
reliable,  and  aalntalnable.  It  is  based  on  the  following  concepts: 

* Structuring  a systea  as  a hierarchy  of  Independent  units, 
whose  interconnections  to  other  units  of  the  hierarchy  are 
well  defined.  The  structuring  involves  data  as  well  as 
control . 

* Foraally  specifying  — in  a preoise,  aatheaatical  language 
— each  of  the  coaponents  of  a systea  by  stating  what 
coaponent's  function,  independently  of  how  the  component 
perforas  the  specified  function. 

* Foraally  verifying,  via  a aatheaatical  proof,  that  the 
iapleaentation  of  a given  system  meets  its  specifications. 

These  principles  result  in  better  designs,  more  reliable  systeas,  and 

easier  maintenance. 

HDH  divides  the  software-development  process  into  the  following 
stages: 

■ Conceptualization,  in  which  the  problem  to  be  solved  is 
formulated  in  detail. 

* External  Interface  Definition,  in  which  the  external 
interfaces  of  the  systea,  their  component  parts,  and  the 
functions  of  each  part,  are  identified. 

■ Intermediate  Interface  Definition,  in  which  the  parts  of 
the  internal  interfaces  of  the  systea,  and  the  component 
functions  of  each  part,  are  identified. 

* Formal  Specification,  in  which  formal  specifications  are 
written  for  each  part  of  the  systea. 

* Foraal  Renreaentation.  in  which  the  data  structures  of  a 
coaponent  of  the  hierarchy  are  defined  in  terms  of  the  data 
structures  of  more  primitive  coaponents. 

* Abstract  Implementation,  in  which  abstract  (descriptive) 
programs  are  written  to  implement  each  function  of  the 
systea . 

* Codina.  in  which  the  abstract  programs  are  translated  into 
runnable  source  code. 
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• Foraal  Varlfleatlon.  in  which  the  consistency  of  the 
specifications  and  the  abstract  programs  is  formally 
proved.  This  stage  is  optional,  and  is  performed  only  in 
cases  where  the  reliability  of  the  system  is  important 
I • enough  to  Justify  its  large  cost. 

More  information  on  HDM  can  be  found  in  [2]  and  [3]« 

I . 
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Ill  THE  REUTIONSHIP  OF  HDH  AND  THE  PPS 


The  PPS  (Program  Performance  Specification)  is  a statement  of  the 
requirements  — performance,  functional,  and  equipment  — - of  an  embedded 
system.  The  PPS  is  generated  before  the  software  is  designed,  and 
should  not  contain  any  discussion  of  design  or  implementation  Issues. 

The  PPS  properly  corresponds  to  the  first  (conceptualisation)  stage 
of  HDH.  HDH  currently  provides  no  language  for  formally  stating 
requirements,  so  — in  general  — there  is  no  document  of  HDH  that  can 
be  used  in  the  PPS.  However,  if  the  use  of  a particular  piece  of 
hardware  (e.g.,  processor,  disk  drive,  terminal)  is  specified  as  part  of 
the  requirements,  its  formal  specifications  can  be  written  using  KON  and 
Inserted  into  the  PPS.  In  addition,  HDH  provides  a particular  way  of 
looking  at  requirements  and  often  provides  criteria  for  stating  them 
more  cleanly  (for  example,  separating  them  fbom  design  issues). 

Thus,  HDH  provides  a conceptual  basis  for  the  PPS  and  formal 
specifications  for  any  hardware  components  that  are  part  of  the  system 
requirements. 


IV  THE  REUTIONSHIP  OF  HDH  AND  THE  PDS 


The  PDS  (Program  Dealgn  Specification)  is  a statement  of  the  design 
details  of  sn  embedded  system.  It  always  contains  a description  of  the 
structure  of  the  system,  and  in  many  cases  uses  flowcharts  to  specify 
the  functions  of  system  components.  It  is  assumed  that  a team  of 
programmers,  using  only  the  PDS,  could  be  assigned  to  code,  integrate, 
and  maintain  a software  system. 

The  PDS  corresponds  to  the  HDM  stages  of  external  Interface 
definition,  internal  Interface  definition,  formal  specification,  formal 
representation,  and  abstract  implementation.  The  correspondence  between 
the  PDS  and  the  first  three  of  these  stages  is  clear.  The  outputs  of 
these  stages  describe  the  structure  of  the  system  and  the  behavior  of 
each  component,  and  should  be  definitely  Included  in  the  PDS  as 
requirements  to  be  met  by  the  Implementations  of  the  system.  However, 
the  correspondence  between  the  PDS  and  the  last  two  of  the  above  stages 
is  open  to  Interpretation.  The  outputs  of  these  stages  describe  the 
definitions  of  data  structures  of  various  components  of  the  hierarchy 
and  the  implementations  of  all  f'lnetions  in  the  system,  and  should  also 
be  included  in  the  PDS.  However,  should  they  be  Interpreted  as  strict 
requirements  or  merely  guidelines?  The  answer  will  probably  vary 
according  to  individual  circumstances. 

One  advantage  of  incorporating  HDM  specifications  into  the  PDS  is 
that  HDM  specifications  are  more  uniform  and  more  precise  than  those  of 
conventional  techniques,  including  flowcharts  and  pseudocode.  Thus, 
using  HDM,  the  PDS  becomes  more  precise  and  uniform.  The  Incorporation 
of  documents  produced  using  HDM  enhances  the  major  goal  of  the  PDS, 
i.e.,  to  communicate  the  intent  of  the  system  designers  to  those  who 
must  implement,  integrate,  test,  and  maintain  the  system. 
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Thus,  the  bulk  of  the  outputs  of  HDM  should  be  Included  In  the  PDS, 
since  they  fora  a basis  for  iapleaentatlon  and  maintenance  of  the 
systea.  The  required  sections  of  the  PDS  concerning  the  approaches  to 
prograning,  integrating,  and  aalntaining  the  systea  are  directly 
derivable  froa  the  rules  of  HOM.  As  a result,  there  is  little  in  the 
PDS  that  HDH  does  not  provide. 
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V THE  RELATIONSHIP  OF  HOH  AND  THE  SOW 


The  SOW  (Statenent  of  Work)  Is  an  integral  part  of  the  process  by 
which  the  Navy  procurer  embedded  systems  from  outside  sources.  It  can 
specify  both  the  tasks  to  be  performed  and  the  method  for  performing 
them. 

HDH  can  assist  in  the  procurement  of  software  systems  in  several 

ways: 

* In  the  procurement  of  an  entire  system,  including  both 
design  and  implementation,  the  use  of  HDM  can  be  required. 

The  use  of  HDH  will  aid  in  monitoring  the  progress  of  the 
contract,  because  of  the  formal  specifications  and  tools 
that  aid  in  the  design  process.  In  addition,  the  system 
produced  will  probably  be  better,  and  certainly  more  easy 

, to  maintain. 

* In  the  procurement  of  the  implemontatlon  for  a previously 
designed  system,  HDM  specifications  can  be  generated  as  the 

< output  of  the  design  process  and  can  be  used  in  the  RFQ  as 

requirements  to  be  placed  on  the  implementation  effort. 

Such  formal  specifications  provide  more  information,  in  a 
more  precise  way,  than  do  conventional  English 
specifications. 

* In  the  procurement  of  the  verification  of  a system,  HDM  can 
be  required  as  the  method  for  specifying  and  formally 
proving  the  desired  properties.  There  are  two  types  of 
verification  supported  by  HDM:  design  verification,  in 
which  certain  properties  (e.g.,  security,  reliability)  are 
proved  based  only  on  the  specifications  for  the  design  of 
the  system;  and  implementation  verlfioatlons,  in  which  the 
system's  Implementation  is  proved  consistent  with  the 
specification.  HDM  oan  be  used  in  both  types  of 
verification. 


Thus,  the  formal  specifications  and  precise  thinking  required  by  HDM  can 


VI  CONCLUSIONS 


Although  MOM  provides  • new  fraaework  for  thinking  about  the 
structure  of  eabedded  aysteas,  it  divides  the  software-developaent 
process  into  stages  that  are  entirely  consistent  with  the  stages  of  the 
Navy  software-developoent  process.  In  fact,  software  developaent  using 
HDH  actually  enhances  the  Navy  software-developoent  process,  because  the 
outputs  of  HDH  fit  readily  into  Navy  documents. 
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